A content delivery network (CDN) may be a network of servers that delivers pieces of content (e.g., web pages, audio, video, etc.) to end users, typically on behalf of a content provider. A CDN typically disperses its servers across geographically different locations, and copies the media content to each of those distributed servers, where it's stored (cached). When a user requests a particular piece of media content from the content provider that is stored in the CDN, the CDN is capable of redirecting the request to a server in its network that is closer/closest to the user, and that server in turn delivers the content directly from its cache (first retrieving it from the originating server if the cached copy cannot be found). CDNs are effective in speeding the delivery of content of Web sites with high traffic and Web sites that have global reach. The closer the CDN server is to the user geographically, the faster the content is typically delivered to the user. CDNs also provide protection from large surges in traffic. The process of accessing content via a CDN is typically transparent to the user.
Ideally, a CDN should be able to deliver content requested by an end user regardless of the user's geographic location or the service provider through which the user is connected. However, the footprint of the CDN might not reach far enough to reach that user (geographically or in terms of network connectivity), or might not be close enough to the user to gain the benefits (e.g., reduced access latency) that a more distributed CDN could provide. In those cases, a CDN interconnect (CDNi) model becomes desirable, whereby several standalone CDNs collaborate so that their collective footprint can be extended. Typically, CDNi setups have a primary CDN with whom the content provider has a business relationship and which is the main party responsible for handling that Content Provider's traffic. At the same time, the primary CDN also has peer relationships with other CDNs, and whenever it needs their help (e.g., to serve content outside its own footprint) its servers follow agreed-upon protocols that communicate with a secondary CDN's servers and ask them to handle the corresponding requests on their behalf.
In order to securely deliver content to a requesting user or client, a CDN edge server (also referred to as a surrogate) uses content metadata, e.g. information about how the content must be handled. The content metadata may include, e.g., geo-blocking policies, availability windows, links to the source of the content, etc. When a request for a piece of content arrives at the surrogate, the server examines the corresponding metadata and makes a decision about if and how to honor the request. CDN metadata is typically prepositioned statically to the edge surrogates, i.e., the metadata is pushed to each surrogate from a CDN's central unit of control. The surrogate must receive the content metadata before serving a request. This requires the CDN provider to schedule time to update all surrogates before a piece of content can be served. In a CDN-Interconnect (CDNi) environment, where two or more CDNs collaborate with each other to deliver content, the CDNi metadata may be shared across CDNs. However, the preposition/push method becomes unscalable and difficult to manage because there may be too many surrogates to update, and the original CDN might not know how many surrogates the secondary CDN has or where they are. In addition, metadata refresh cycles in the two CDNs might not be synchronized, and the primary CDN may not be able to determine whether the update effort is worth the resource expense with respect to some surrogates, since the original CDN may never ask the second CDN to serve the corresponding content on its behalf.